Created attachment 380310 [details] KDE 4 Power Management System Settings on F12 and Kubuntu 9.10 I have installed F12 (no upgrade, just new install) and kde 4 power management in system settings says that CPU frequency scaling is not supported. Previously on F10 with Guidance Power Manager it was working fine, just in case I have checked the latest kubuntu and in kubuntu it works fine. Cpuspeed is working and I can manually change CPU frequency with cpufreq-set. Hardware details: Toshiba L40-14F laptop. cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 1467000 1067000 800000 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors ondemand userspace performance cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Pentium(R) Dual CPU T2310 @ 1.46GHz stepping : 13 cpu MHz : 800.000 cache size : 1024 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm bogomips : 2925.94 clflush size : 64 power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Pentium(R) Dual CPU T2310 @ 1.46GHz stepping : 13 cpu MHz : 800.000 cache size : 1024 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm bogomips : 2925.86 clflush size : 64 power management:
Upstream please. If it matters any, many experts advise using the default cpu scaling policy for best results, http://www.codon.org.uk/~mjg59/power/good_practices.html
ok, nevermind about upstream, does appear to be fedora specific (if I take the second ubuntu screenshot to imply it working there).
solid-powermanagement query cpufreq please. Seems not to work for me on f12/kde-4.3.85, $ solid-powermanagement query cpufreq solid-powermanagement(7283)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open ksycoca from "/var/tmp/kdecache-rdieter1/ksycoca4" solid-powermanagement(7283)/kdecore (KLibrary) kde4Factory: The library "/usr/lib64/kde4/solid_hal_power.so" does not offer a qt_plugin_instance function.
solid-powermanagement query cpufreq runs and shows no output. just in case I have downloaded F11 Kde live and it shows available governors. I agree with experts, but it's about principles :) if something's broken must be fixed.
This bug has been triaged Steven M. Parrish KDE & Packagekit Triager Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
*** Bug 562542 has been marked as a duplicate of this bug. ***
Bug's still present after recent push to KDE 4.4.0 on Intel Core2Duo P8400, which definitely supports scaling.
I found that since version 0.5.13-6 fedora compiles hal with the --without-cpufreq option. http://cvs.fedoraproject.org/viewvc/rpms/hal/F-12/hal.spec?revision=1.209&view=markup So no hald-addon-cpufreq in hal, no scaling capability in KDE Regards
=> Reassigning to HAL.
We need cpufreq reenabled in HAL, KDE still needs this!
(In reply to comment #10) > We need cpufreq reenabled in HAL, KDE still needs this! No, HAL upstream is dead, and we're slowly throttling back on supported features. In F14 HAL should cease to exist at all. If you're changing the cpufreq governor nowadays as part of a power-saving scheme, then you're really doing something terribly wrong.
> No, HAL upstream is dead That's an exaggeration. It's in maintenance mode. A truly dead upstream looks different (there are no commits at all, just a years-old tarball). > and we're slowly throttling back on supported features. I don't think it's acceptable that you're disabling HAL features without even talking to us KDE folks about it, KDE being the biggest remaining user of HAL. In fact, we only noticed KDE is missing a feature and had no idea why until somebody traced it down to the feature being disabled in HAL. > In F14 HAL should cease to exist at all. "Should", sure, are you doing the work on porting KDE away from it? Thought so. KDE upstream has just started working into that direction as part of some major Solid reorganizations, this may or may not be ready in 4.5 (which is what F14 will presumably ship). > If you're changing the cpufreq governor nowadays as part of a power-saving > scheme, then you're really doing something terribly wrong. KDE upstream does not agree with that assessment, and I don't see why we are, and should in your opinion keep, shipping a crippled version of their software just because you have a different opinion about that.
(In reply to comment #11) > If you're changing the cpufreq governor nowadays as part of a power-saving > scheme, then you're really doing something terribly wrong. Governor, sure. Everyone should really be using ondemand. However, what would be nice is to be able to actually *turn it on* under a KDE based system, not only that, but to perhaps disable it under certain circumstances. Currently under a fresh Fedora KDE 4.4 install my laptop does not enable any CPU scaling at all. I can't enable it under KDE because it doesn't work.. Of course, I can control this by the command line, but it would still be nice to have it working under KDE. -c
(In reply to comment #12) > I don't think it's acceptable that you're disabling HAL features without even > talking to us KDE folks about it, KDE being the biggest remaining user of HAL. > In fact, we only noticed KDE is missing a feature and had no idea why until > somebody traced it down to the feature being disabled in HAL. Sure, and if we enable the feature, and somebody reports bugs on it, who gets to fix them? Me. > "Should", sure, are you doing the work on porting KDE away from it? Thought so. > KDE upstream has just started working into that direction as part of some major > Solid reorganizations, this may or may not be ready in 4.5 (which is what F14 > will presumably ship). I'm not sure why I should be doing any KDE work. It's been known for a couple of years now that HAL is being deprecated. > KDE upstream does not agree with that assessment, and I don't see why we are, > and should in your opinion keep, shipping a crippled version of their software > just because you have a different opinion about that. Well, I seem to have the same opinion as the kernel guys who actually add the functionality to the kernel. Please read http://www.codon.org.uk/~mjg59/power/good_practices.html
(In reply to comment #13) > Currently under a fresh Fedora KDE 4.4 install my laptop does not enable any > CPU scaling at all. I can't enable it under KDE because it doesn't work.. It should be doing ondemand by default. If not, it's a kernel bug.
After discussing the issue a bit with hughsie and some kernel folks, here's the deal: it was agreed (speaking for myself anyway) that fedora's default ondemand governor is very good, and not using it is generally a bad idea. Further, to re-enforce comment #15 , if the ondemand doesn't work well for you, it is considered a kernel bug, and can/should be fixed there.
Now, if after all that anyone is still not convinced to simply use the ondemand default, I'm willing to spin up some unofficial hal rpms re-enabing this feature.
See also, Summary: powerdevil: Remove CPU frequency scaling interfaces http://reviewboard.kde.org/r/3206/
After reading the following: http://www.codon.org.uk/~mjg59/power/good_practices.html http://reviewboard.kde.org/r/3206/ I have to agree that there are legitimate reasons to _disable_ the CPU frequency scalling support in KDE 4.4.x. However my laptop has a 3+ year old AMD turion 2.0 GHz processor limited to c1 state. On the top of this, the mobo has also come to its limits. Nowadays flash is _sadly_ one of the most widely used applications on the internet. And it's quite a big cpu hog. Therefore I frequently reach temperatures above 90C which are the bareable limit for the cpu (the not so good xorg-x11-drv-ati is also to mention here). These make the cpu downclock in oder to save it. Therefore I frequently come across situations where I can justify the use of the powersave governor. This is also described as "Some systems have poor cooling mechanisms and so may overheat under heavy CPU load. One common attempt to work around this is to limit the maximum speed of the processor in order to reduce its heat output. However, this prevents the processor from running at full speed even when it's not in danger of overheating. This will result in it taking longer for the CPU to enter idle states, ironically resulting in it becoming hotter than neccesary and consuming more energy. Summary: If users need to perform thermal management of their systems, write an application that monitors the temperature and limits the CPU speed appropriately. Don't attempt to perform thermal management by using power management functionality to statically limit the processor frequency. " in http://www.codon.org.uk/~mjg59/power/good_practices.html So, what should I do? Can someone made a separate hal-old-laptops-package (with cpu-frequency-scalling enabled) that is to be installed only on laptops which do need this cpu scaling. Maybe this way the current situation can be circumvented without the need to recompile the hal everytime. I know this is not a perfect solution but there are some rare cases where this support is still needed.